The invention relates to serial advanced technology attachment (SATA) devices, and more particularly, to a method of correcting primitives that have become corrupted due to noise.
In the SATA protocol, the host and the device exchange information through Frame Information Structures (FIS). Each FIS is composed of a group of Dwords, and the Dwords convey information between the host and the device. The SATA host and SATA device utilize primitives for control purposes and to provide a status of the serial line. Each primitive is also made up of one Dword. Primitives are also used to perform handshaking between a host and a device.
Please refer to FIG. 1 . FIG. 1 is a table 10 illustrating byte contents of primitives used in the SATA protocol. Each primitive contains four bytes, and the contents of the first, second, third, and fourth bytes are shown in columns 12, 14, 16, and 18, respectively.
Please refer to FIG. 2. FIG. 2 is a diagram showing an example of sending a frame between a host and a device. The host can either be a transmitter 100 or a receiver 200, with the receiver being the other. In FIG. 2, the transmitter 100 transmits a series of data or primitives 102-188 to the receiver 200, and the receiver 200 responds with primitives 202-288 to be sent to the transmitter 100.
In FIG. 2, the transmitter 100 starts off by transmitting sync primitives followed by scrambled data packets 102, 104 to the receiver 200. The symbol “XXXX” represents the scrambled data values, and these data packets 102, 104 are not primitives. The scrambled data is used to reduce the effects of electromagnetic interference (EMI). When the transmitter 100 is ready to begin transmitting a frame to the receiver 200, the transmitter 100 outputs a transmission data ready (X_RDY) primitive indicating that the transmitter 100 is ready to transmit payload to the receiver 200. In this example, the transmitter 100 sends two X_RDY primitives 106, 108, issues a continue repeating previous primitive (CONT) primitive 110 to avoid having to output the same primitive repeatedly, and then outputs a series of scrambled data packets 112-118. The transmitter 100 continues this until the receiver 200 responds to the X_RDY primitives with a receiver ready (R_RDY) primitive, indicating that the receiver 200 is ready to receive the payload. In this example, the receiver 200 sends two R_RDY primitives 214, 216, issues a CONT primitive 218, and then outputs a series of scrambled data packets 220-224 until the transmitter 100 starts transmitting the frame.
The transmitter 100 sends a start of frame (SOF) primitive 120 to the receiver 200 to indicate that the frame is starting to be transmitted. Next, the transmitter 100 sends a type indicator 122 to specify the type of FIS that is being sent to the receiver 200, followed by a plurality of data packets 124-130. While the receiver 200 is receiving data from the transmitter 100, the receiver 200 outputs reception in progress (R_IP) primitives 226, 228 to the transmitter 100 followed by a CONT primitive 230 and scrambled data 232-238. When the transmitter 100 temporarily does not have any payload data ready for transmission, a hold data transmission (HOLD) primitive is output. As shown in FIG. 2, the transmitter 100 outputs HOLD primitives 132, 134 followed by a CONT primitive 136, scrambled data 138-142, and followed by another HOLD primitive 144. The receiver 200 acknowledges these HOLD primitives with hold acknowledge (HOLDA) primitives 240, 242 followed by a CONT primitive 244 and scrambled data 246-252.
The transmitter 100 then finishes sending the payload data with data packets 146-150, followed by cyclic redundancy check (CRC) data 152 and an end of frame (EOF) primitive 154. Next, the transmitter 100 continuously outputs wait for frame termination (WTRM) primitives 156-158, a CONT primitive 162, and scrambled data 164-170 while waiting for an indication of reception status from the receiver 200. The receiver 200, meanwhile, finishes receiving the payload data from the transmitter 100 and outputs R_IP primitives 254, 256 followed by a CONT primitive 258 and scrambled data 260, 262. After the receiver 200 has received all payload data, the CRC 152, the EOF 154, and verified that the CRC check has no problems, the receiver 200 then outputs reception with no error (R_OK) primitives 264, 266 followed by a CONT primitive 268 and scrambled data 270-278. If the CRC check did have problems, then the receiver 200 would instead output a reception error (R_ERR) primitive. Once the transmitter 100 has received the R_OK primitive from the receiver 200, the transmitter 100 then outputs synchronizing primitives (SYNC) 172, 174, followed by a CONT primitive 176 and scrambled data 178-188. The SYNC primitives are output when the transmitter 100 is idle, and also serve the purpose of synchronizing the transmitter 100 and the receiver 200. The receiver 200 will respond with SYNC primitives 280, 282, a CONT primitive 284, and scrambled data 286, 288 of its own.
The above scenario is illustrative of sending a frame of payload data without any transmission problems. However, noise can interfere with the transmission of primitives and data, which can cause communication problems between the transmitter 100 and the receiver 200. For instance, if the receiver 200 is not able to decode a SOF primitive sent from the transmitter 100, the receiver 200 will continue to send out a R_RDY primitive forever. However, the transmitter 100 will not know that the receiver 200 did not receive the SOF primitive, and will still send out data to the receiver 200 until the data transfer is complete, finishing by sending a WTRM primitive to the receiver 200. The receiver 200 will respond to the WTRM primitive with a SYNC primitive because it never received the SOF primitive at the beginning of the data transmission. Communication between the transmitter 100 and the receiver 200 may then hang at this point because the receiver 200 does not send either an R_OK or R_ERR primitive to the transmitter 100.
Another potential problem will result if HOLD, HOLDA, CONT, or EOF primitives are corrupted by noise. If these primitives are corrupted by noise, it may result in the wrong data transfer length. If the CRC check or 8-bit to 10-bit (8b10b) decoding are not able to identify this problem, then the problem may result in a system hang.
Additionally, if the HOLD, HOLDA, or CONT primitives are corrupted by noise, the transmitter 100 may send out too much data and overflow the first-in first-out receiving queue of the receiver 200. Because noise cannot always be eliminated entirely, there must be a way of overcoming the problems of corrupted primitives caused by noise.